Network congestion can basically appear in any part of a complex communication network where potential bottlenecks may occur as a result of insufficient network throughput capacity in relation to the (momentary) communication traffic load. One common example, which will be adhered to in this document, is the transport network in a mobile telecommunications system.
In recent years, the functionality offered by mobile telecommunications systems has been expanded from pure (circuit-switched) voice communication to a variety of services in addition to voice calls. Many of these additional services employ packet-switched data communication between a server and a mobile terminal, or between two mobile terminals, over the mobile telecommunications network and associated wide area networks such as the Internet. For instance, the 3G/UMTS (3rd Generation/Universal Mobile Telecommunications System) architecture involves packet-based communication in accordance with the High Speed Packet Access (HSPA) protocol set, including High Speed Downlink Packet Access (HSDPA) for downlink communication and High Speed Uplink Packet Access (HSUPA), also known as Enhanced Uplink (EUL), for uplink communication. These protocols are defined in the 3rd Generation Partnership Project (3GPP) specifications.
In any packet-switched communication system, problems like packet losses or congestion between competing data flows can occur at various locations in the system. Data flow control is therefore provided at several levels in the protocol architecture. For instance, in the 3G/UMTS (3rd Generation/Universal Mobile Telecommunications System) architecture, the Transmission Control Protocol (TCP) may be applied on an upper level between a TCP server and an end-user application in a mobile terminal (user equipment, UE). Radio Link Control (RLC) is applied between a Serving Radio Network Controller (SRNC) and a UE, whereas HSPA Flow Control (FC) is applied to HSPA traffic flows over the Transport Network (TN; Iub) between an SRNC and a Radio Base Station (RBS; Node B).
Efficient congestion control is complicated by the fact that the different protocols involved terminate at different locations in the network. This problem situation has been addressed in WO 2010/107348, which takes the position that TCP cannot efficiently resolve a congestion situation in the radio access network (which includes the transport network), because lower layer retransmissions hide the congestion situations from TCP. Instead, WO 2010/107348 introduces an improved HSPA Flow Control (FC) which is performed by a radio base station and which in particular seeks to obtain proportional fair bandwidth sharing among contending traffic flows over the transport network. For this purpose, a relative bit-rate (RBR) weight is assigned to each traffic flow, which will cause the HSPA Flow Control to favor traffic flows having a higher RBR weight over those having a lower RBR weight. The RBR concept allows Quality of Service (QoS) bit-rate differentiation between different types of end-user subscriptions. HSPA Flow Control involves a rate-based congestion control which operates in a Congestion Avoidance (CA) state according to an operating principle known as Additive Increase Multiplicative Decrease (AIMD). In WO 2010/107348, QoS bit-rate differentiation in accordance with the RBR concept is effected by modifying the AI part of the AIMD operating principle.
Some attempts have been made to use the TCP acknowledgement scheme for congestion control purposes in the transport network, despite RLC hiding congestion problems to TCP. If a TCP server receives repeated acknowledgements for previous TCP data but not for the most recently sent TCP data, the congestion control/congestion avoidance functionality in the TCP server will infer this as a congestion condition somewhere on the network and, in response, reduce the bit-rate for the forthcoming transmission by a certain rate. When a network node, such as a radio base station, detects congestion in the transport network, it may signal this to the TCP server by deliberately modifying the contents of current TCP data towards a receiving TCP client in a way such that the TCP client will interpret the received current TCP data as lost or destroyed and therefore discard it. As a result, the TCP client will acknowledge the previous TCP data, once subsequent TCP data has been correctly received. When this has occurred a number of times, the congestion control/congestion avoidance functionality in the TCP server will act to reduce the bit-rate for the forthcoming transmissions in the TCP session in question. Therefore, by causing discarding of TCP data in this way, the radio base station will in effect be capable of performing congestion control by initiating a bit-rate reduction for the TCP session, even though the actual bit-rate reduction is not executed by the radio base station.
A network node in the form of a radio base station will typically handle a plurality of data connections over the transport network, where each data connection (often referred to as Radio Access Bearer, RAB) is adapted to convey data packets travelling between the core side and terminal side of the transport network. Each data connection may handle a varying number of ongoing TCP sessions between one or more TCP servers and a TCP client running in a mobile terminal for a certain end-user. This complicates the congestion control to be performed by the radio base station in the transport network, and the problem is accentuated if the congestion control is to support QoS bit-rate differentiation between different types of end-user subscriptions among the data connections (RAB:s) handled by the radio base station in question. As a result, the actual QoS bit-rate differentiation obtained may deviate from the target QoS bit-rate differentiation as set for instance by the network operator.
Similar problems may occur in other networks or parts thereof, for instance in the air interface between a radio base station and a plurality of mobile terminals.